Realistisch betrachtet kommen 99 Prozent aller JavaScript-Entwickler:innen mit 99 Prozent der gängigen JavaScript-Features aus. Gerade wenn man sich im Frontend-Framework-Laufstall häuslich eingerichtet hat, beschäftigt man sich vorwiegend mit High-Level-Aufgaben. Dabei ist weniger entscheidend, was die Programmiersprache JavaScript grundsätzlich kann, sondern vielmehr, welche Funktionen die relevanten Abhängigkeiten anbieten. Doch was tun, wenn eine Aufgabe auftaucht, die sich nicht mit der Standardklaviatur bewältigen lässt? Wenn eine Kompatibilitätsschicht geschaffen werden muss, Magic Keys benötigt werden, RPC gefragt ist oder für einen ganz bestimmten Anwendungsfall das Change-Tracking-Rad neu erfunden werden muss?

Für diese und viele andere Fälle hält der ECMAScript-Standard mit dem Proxy API (und seinem Sidekick Reflect API) ein Werkzeug für die Objektmetaprogrammierung bereit. Dieses bereits seit 2015 spezifizierte API ist kein Geheimnis, wird aber von vielen nicht verstanden. Eigentlich sind Proxys nämlich keine Magie und kein Hack, sondern lediglich ein Werkzeug zur Erstellung von Exotic Objects. Diese sind ihrerseits kein Hexenwerk, sondern ein seit langer Zeit etabliertes Kernkonzept von JavaScript. Proxy, Reflect und Exotic Objects sind an sich nichts Besonderes, sondern lediglich das Toolkit für jene wenigen restlichen Fälle, in denen Standard-JavaScript nicht das Mittel der Wahl ist. Die einzige Herausforderung besteht darin, dass wir, wenn wir mit Proxy und Reflect souverän umgehen wollen, gewisse Aspekte der ECMAScript-Spezifikation von Grund auf verstehen müssen. Aber auch das erfordert keinen übermäßig brillanten Verstand; mit etwas Durchhaltewillen und Liebe zum Detail schaffen wir das.

In dieser dreiteiligen Artikelserie widmen wir uns dem Konzept der Exotic Objects im Allgemeinen und dem Proxy und Reflect API im Besonderen. Wir tauchen in die Tiefen der ECMAScript-Spezifikationen ein, erarbeiten uns Wissen um die Features und Grenzen von Exotic Objects und erkunden die APIs von Proxys und dem Reflect Namespace. Am Ende der Serie werden wir Proxys mit schlafwandlerischer Sicherheit produzieren und Exotic Objects erschaffen können. Da wir uns das Thema von Grund auf erarbeiten, werden wir auch in der Lage sein, unseren Exotic Objects ein wohlüberlegtes Design angedeihen zu lassen, Workarounds für Limitierungen zu schreiben und frühzeitig zu erkennen, wann Proxys das Mittel der Wahl sind – und wann nicht.

In diesem ersten Teil der Serie erschließen wir zunächst das Konzept der Exotic Objects – was sie sind, was sie so exotisch macht und wo wir sie finden können. Im Zuge dessen werden wir vergleichsweise tief in die ECMAScript-Spezifikationen einsteigen. Doch bevor wir ohne konkreten Anlass den Absprung in den Abgrund wagen, habe ich eine scheinbar triviale, aber noch offene Frage: Wie funktionieren eigentlich Arrays in JavaScript?

Setze JavaScript Trends um

16. - 20. März 2026

>

Virtuelle Spezifikationen – nichts ist, wie es scheint

Die Programmiersprache JavaScript basiert auf der ECMAScript-Spezifikation, einem umfangreichen Dokument [1], das das Verhalten einer JavaScript-Engine genau beschreibt. Dabei legt die Spezifikation nur das von außen beobachtbare Verhalten von JavaScript fest und verliert wenige Worte über das tatsächliche Innenleben der Engines. Es zählt praktisch nur, dass sich eine JavaScript-Engine wie jede andere JavaScript-Engine verhält. Welche Algorithmen, Datenstrukturen und Memory-Management-Strategien die Engines intern verwenden, bleibt in der Regel offen, und die Implementierungen der verschiedenen Browser unterscheiden sich oft voneinander. Für JavaScript-Entwickler:innen spielt es in der Regel keine Rolle, dass die Garbage Collectors oder die optimierenden Compiler von Browser A und Browser B unterschiedlich sind, solange sich die Programmiersprache in ihren an der Oberfläche sichtbaren Features überall einheitlich verhält. Abweichungen zwischen Browsern bestehen in Details wie Performancecharakteristika oder in der An- bzw. Abwesenheit kompletter Features. Wenn etwas implementiert ist, sollte es jedoch in allen Implementierungen einheitlich funktionieren.

Diese Einheitlichkeit wird unter anderem durch die Spezifikationen sichergestellt. Hier werden abstrakte Algorithmen und Operationen definiert, die ausschließlich innerhalb der Spezifikation selbst verwendet werden, um andere Algorithmen und Operationen zu erklären, die wiederum das beobachtbare Verhalten der Sprache beschreiben. Das macht das Lesen der ECMAScript-Spezifikationen für Laien vergleichsweise anstrengend, denn extrem viel Spezifikationstext ist gewissermaßen virtuell: Eine Subroutine einer Subroutine einer Subroutine beschreibt ein Verhalten, das die Browser am Ende auf technischer Ebene möglicherweise komplett anders umsetzen. In den Spezifikationen geht es jedoch um das Prinzip, um ein System zur Beschreibung des beobachtbaren Verhaltens.

Die Komplexität der Spezifikationen und der hohe Abstraktionsgrad sind dabei kein Selbstzweck, denn das gesamte beobachtbare Verhalten von JavaScript ist nun einmal komplex und umfangreich. Betrachten wir als Beispiel folgende Definition einer neuen Objekteigenschaft:

let o = {};
o.foo = 42;

Auf den ersten Blick sieht das nicht besonders komplex aus, doch erfahrene JS-Hacker und -Hexen wissen, dass die Syntax in der zweiten Zeile eigentlich nur eine Kurzform der folgenden Syntax ist:

Object.defineProperty(o, "foo", {
  value: 42,
  writable: true,
  enumerable: true,
  configurable: true,
});

Die Langfassung macht deutlich, wie komplex vermeintlich einfache Objekteigenschaften tatsächlich sind. So kann der Wert einer Eigenschaft überschreibbar oder unveränderlich sein (writable), eine Eigenschaft kann in for-in- und ähnlichen Iterationsmechanismen auftauchen oder nicht (enumerable) und das gesamte Bündel an Objekteigenschaften kann fest oder veränderlich sein (configurable). Hinzu kommen Interaktionen mit anderen Sprachfeatures wie Strict Mode, with-Statement, Symbols, dem delete-Keyword sowie die Möglichkeit, anstelle von value und writable ein Getter/Setter-Paar zu definieren. Es sollte offensichtlich sein, dass das „gesamte beobachtbare Verhalten“ von JavaScript ein ausgesprochen umfangreiches und komplexes Feld ist, das eine abstrakte und umfassende Spezifikation notwendig macht.

Nicht Teil der Spezifikationen ist, was Browser-Engines unter der Haube mit JavaScript-Code anstellen. Aus der Vogelperspektive betrachtet implementieren V8, JavaScript Core, SpiderMonkey und alle anderen großen Engines ungefähr die gleichen Features auf ungefähr die gleiche Weise. In jeder der genannten JS-Engines finden sich Bytecodes, Just-in-Time-Compiler, Hidden Classes und viele andere Gemeinsamkeiten. Diese gibt es jedoch ausschließlich, weil alle modernen Engines Hochleistungsprodukte sind, die den aktuellen Stand der Technik implementieren und ähnliche Lösungen für gegebene Probleme finden – ein klassischer Fall von konvergenter Evolution.

Dagegen ist die für Embedding-Anwendungsfälle ausgelegte Engine QuickJS [2] intern komplett anders aufgebaut. So wird etwa die JS-Syntax ohne den Umweg eines Parse Trees unmittelbar in Bytecode umgewandelt, um einen schnelleren Start der Ausführung zu ermöglichen. Das ist eher unkonventionell. Was das ECMAScript-Feature-Set und das Verhalten dieser Features betrifft, ist QuickJS von Chrome jedoch nicht zu unterscheiden. Das ist nur möglich, wenn die Spezifikationen ausreichend abstrakt sind und lediglich festlegen, wie sich die Sprachkonstrukte von standardkonformem JavaScript aus der Anwenderperspektive zu verhalten haben.

Aber selbst wenn wir in unserer glücklichen Position die nerdigen C++-Details von JS-Engine-APIs ausklammern dürfen, sind Objekte doch noch etwas komplizierter, als wir das bisher erforscht haben. Bislang haben wir uns nämlich nur mit den Features und Verhaltensweisen von „normalen“ JavaScript-Objekten befasst, doch es gibt auch „weniger normale“ Objekte.

Magie im Array

JavaScript-Arrays sehen auf den ersten Blick aus wie normale Objekte mit ein paar zusätzlichen Methoden. Wir können Arrays mit beliebigen Eigenschaften versehen; jene mit numerischen Namen erhöhen die von length gemeldete Zahl und die zusätzlichen Methoden funktionieren ebenfalls. Außerdem können wir die length-Eigenschaft eines Arrays auch auf einen neuen Wert setzen, um das Array z. B. durch length = 0 zu leeren (Listing 1).

let a = [];
console.log(a.length); // > 0

a.push(23);
console.log(a.length, a[0]); // > 1, 23

a.foo = "a"; // erlaubt und funktioniert
console.log(a.length, a.foo); // > 1, "a"

a[1] = 42;
console.log(a.length, a[1]); // > 2, 42

a.length = 0;
console.log(a); // > []

So weit, so wenig überraschend. Aber wie funktioniert length hier eigentlich? Woher weiß JavaScript, dass nach a[1] = 42 der length-Wert ein Update auf 1 benötigt und dass eine manuelle Veränderung von length den Inhalt des Arrays verändert?

Eine naheliegende Lösung wäre, dass length über ein auf Array.prototype (der Basisklasse aller Arrays) definiertes Getter/Setter-Paar umgesetzt wird, dessen Setter das Array aktualisiert und dessen Getter bei Aufruf die Felder mit numerischen Namen durchzählt. Dass dies aber nicht der Fall ist, erkennen wir daran, dass ein normales Objekt mit Array.prototype als Prototyp dieses Verhalten nicht zeigt:

let a = Object.create(Array.prototype);
a[0] = 23;
a[1] = 42;
console.log(a.length, a[0], a[1]); // > 0, 23, 42
a.length = 0;
console.log(a.length, a[0], a[1]); // > 0, 23, 42

Wäre length ein Getter/Setter-Paar, hätte dasselbe Ergebnis wie bei Listing 1 herauskommen müssen, doch das ist offensichtlich nicht der Fall. Wenn wir die Array-Eigenschaft length direkt inspizieren (Listing 2), sehen wir stattdessen, dass dort keine Getter oder Setter vorhanden sind.

let a = [];
Object.getOwnPropertyDescriptor(a, "length");  
/* {
  value: 0,
  writable: true,
  enumerable: false,
  configurable: false,
} */

Das von Object.getOwnPropertyDescriptor() gemeldete Ergebnis ist ein Data Descriptor, also eines der zuvor gesehenen Bündel aus writable, enumerable, configurable und value. Ein Accessor Descriptor, der aus einer Getter/Setter-Definition hervorgeht, sähe hingegen anders aus (Listing 3).

let b = { get length() {}, set length(x) {} };
Object.getOwnPropertyDescriptor(b, "length");
/* {
  get: length(),
  set: length(x),
  enumerable: true,
  configurable: true,
} */

Ohnehin sollte ein ordnungsgemäßes Getter/Setter-Paar auf dem Prototyp eines Objekts definiert sein. Demnach müsste Object.getOwnPropertyDescriptor() für length auf einem Array undefined ausgeben – doch nichts dergleichen ist der Fall. Es scheint, als wäre length eine ganz normale Objekteigenschaft von Arrays: eine einfache Zahl, die sich auf magische Weise zusammen mit dem Array-Inhalt automatisch verändert und ihrerseits bei Veränderungen den Array-Inhalt auf nicht weniger wundersame Weise zu mutieren vermag. Was geht hier vor?

Normale und weniger normale Objekte

Die ECMAScript-Spezifikation unterscheidet normale Objekte („Ordinary Objects“) von den sogenannten „Exotic Objects“. Arrays fallen in die letztere Kategorie und haben daher Features und Verhaltensweisen, die normale Objekte nicht haben. Die Grenzziehung verläuft dabei entlang der internen Methoden von Objekten und nicht etwa danach, ob die Objekte aus Entwicklungsperspektive ein besonders seltsames Verhalten an den Tag legen. Arrays sind zwar alltäglich, aber technisch gesehen Exotic Objects, während FinalizationRegistry-Instanzen [3] kaum Verwendung finden, aber trotzdem in die Kategorie „Ordinary Objects“ fallen. Nicht der Use Case oder der subjektive Vibe-Check eines Objekts ist entscheidend, sondern welche Effekte Operationen haben, die mit Standardsprachmitteln erzielt werden.

Wenn wir die ECMAScript-Spezifikationen beim Wort nehmen, implementiert jedes JavaScript-Objekt zwischen 11 und 13 interne Methoden, die die grundlegendsten Operationen auf diesem Objekt umsetzen. Diese internen Methoden haben Namen wie [[Get]], [[Set]] oder [[Delete]] und bilden den Unterbau der JavaScript-Sprachkonstrukte, die wir Entwickler:innen im Alltag verwenden. Die eckigen Klammern markieren in der ECMAScript-Notation interne Slots, die wir uns als extraprivate Felder und Methoden auf Objekten vorstellen können. Wie immer gilt: Nichts von alledem muss sich am Ende des Tages tatsächlich in Objekten wiederfinden, aber Objekte müssen sich verhalten, als hätten sie interne Methoden namens [[Get]], [[Set]] und [[Delete]]. Für den Rest dieses Textes werden wir also so tun, als würde sich jeder interne Slot auf jedem Objekt genauso manifestieren, wie er abstrakt spezifiziert ist.

Was genau bedeutet es nun, wenn „interne Methoden den Unterbau von Sprachkonstrukten bilden“? Das ist an einem Beispiel schnell erklärt: Wenn wir z. B. delete o.x ausführen, passieren (vereinfacht gesagt) nacheinander zwei Dinge:

1. Mit dem delete-Keyword verknüpfte Logik wird ausgeführt. Dabei wird unter anderem der Ausdruck o.x rechts vom delete-Keyword ausgewertet und geprüft, ob o auch wirklich ein Objekt und kein Primitivtyp ist.

2. Das eigentliche Löschen findet statt, indem o.[[Delete]](x) ausgeführt wird.

Das delete-Keyword verbindet also eigene Logik mit der Delegation an o.[[Delete]]. Dadurch können Objekte durch ihre internen Methoden selbst bestimmen, wie das Konzept „löschen“ bei ihnen umgesetzt wird. Delete wirkt dabei primär als syntaktischer Zucker für eine durch einen internen Slot definierte Operation. Insgesamt existieren die in Tabelle 1 aufgeführten internen Operationen.

Diese Operationen finden sich bei allen JavaScript-Objekten, wobei sie jeweils mit dem exakt gleichen API aufwarten (z. B. (propertyKey: string | symbol) → boolean bei [[Delete]]). Auf fast allen JavaScript-Objekten haben diese Operationen die exakt gleichen Auswirkungen. Die ECMAScript-Spezifikationen definieren ein Standardset interner Operationen mit Namen wie OrdinaryGet, OrdinarySet oder OrdinaryDelete. Diese lassen sich als Normalfälle verstehen und haben die Effekte, die man üblicherweise erwarten würde. So würde die syntaktische Konstruktion delete o.x zum Aufruf von o[[Delete]](“x”) führen, was wiederum normalerweise an OrdinaryDelete(o, “x”) weitergereicht wird – mit den bekannten Effekten:

• wenn o[“x”] nicht existiert: return true.

• wenn o[“x”] nicht configurable und daher nicht löschbar ist: return false.

• andernfalls: o[“x”] löschen und return true.

Objekte, die für sämtliche interne Operationen die Standard-Ordinary-Operation verwenden, gelten als Ordinary Objects; jene, die eine oder mehrere abweichende Methoden haben, sind Exotic Objects. Letztere sind, wie gesagt, nicht notwendigerweise besonders „exotisch“ im Wortsinne, und nicht alle Objekte mit eher ungewöhnlichen Verhaltensweisen sind Exotic Objects. So gelten etwa WeakRef-Objekte als ganz normale Ordinary Objects, obwohl sie sehr seltsame Hexereien mit dem Speichermanagement betreiben. Ihre internen [[Get]]-, [[Set]]- und [[Delete]]-Operationen sind aber allesamt die gleichen wie bei normalen JavaScript-Objekten, weswegen WeakRef-Objekten das Exotic-Label verwehrt bleibt. Hingegen fallen unsere guten alten Arrays, die im Alltag allgegenwärtig und gar nicht so exotisch erscheinen, in die Kategorie „Exotic Objects“.

Die nicht besonders exotischen Array Exotic Objects

Wir haben gesehen, dass Object.create(Array.prototype) Objekte produziert, die mit Arrays fast identisch sind, ihnen aber nicht exakt gleichen. Der Unterschied zeigte sich bei der length-Property, die sich bei echten Arrays auf „magische“ Weise selbst aktualisieren konnte und sich bei Bedarf wie ein Setter verhielt. Diese Besonderheit rührt daher, dass echte Arrays eine eigene Nicht-Standard-Implementierung der internen Methode [[DefineOwnProperty]] haben. Die Definition von Array Exotic Objects [4] legt fest, dass Arrays nur dann echte Arrays sind, wenn ihre interne [[DefineOwnProperty]]-Methode für den Aufruf a.[[DefineOwnProperty]](property, descriptor) wie folgt arbeitet:

• Wenn property den Wert “length” hat, ist die Array-Länge auf den von descriptor beschriebenen Wert zu setzen. Dabei werden bei Bedarf Array-Felder gelöscht oder neu angelegt.

• Wenn andernfalls property ein Array-Index, d. h. eine nicht negative ganze Zahl ist, wird das entsprechende Array-Feld mit dem von descriptor beschriebenen Wert belegt und die length je nach Notwendigkeit angepasst.

• Andernfalls wird OrdinaryDefineOwnProperty(a, property, descriptor) aufgerufen und somit das Standardverhalten von normalen Ordinary Objects verwendet.

Diese [[DefineOwnProperty]]-Methode wird auf Arrays durch das Spezifikationshilfskonstrukt ArrayCreate(length [, proto]) installiert, das bei Aufrufen des Array-Constructors und bei der Verwendung eines Array-Literals zum Einsatz kommt. ArrayCreate() legt ein neues Objekt an, setzt den Prototyp auf proto (mit Array.prototype als Standardwert) und installiert abschließend die oben beschriebene Implementierung von [[DefineOwnProperty]]. Die eigentlichen Spezifikationen formulieren den gesamten Prozess sowie die Implementierung der internen Methode selbstverständlich unter Einbeziehung zahlloser Sonderfälle (vor allem rund um Typumwandlung) noch etwas präziser.

Am Ende bleibt festzuhalten: Arrays haben besondere Algorithmen für ihre Indizes und die length-Property, während sie alle anderen Felder und alle anderen Operationen genau so behandeln, wie normale Objekte es tun würden. Weil sie aber in diesem einen Aspekt ein wenig von normalen Objekten abweichen, sind sie selbst keine normalen Objekte mehr, sondern rücken in den auserlesenen Kreis der Exotic Objects auf. In folgender Übersicht werden einige Exotic Objects aufgelistet.

• Arrays (magische length)

• String-Objekte (übersetzen Indizes in Unicode-Einheiten)

• Typed Arrays (übersetzen Indizes in Byte-Offsets im zugrunde liegenden ArrayBuffer)

• Object.prototype (Beispiel für ein ImmutablePrototypeExoticObject, dessen Prototype nur auf null gesetzt werden kann)

• Module Namespace Objects, z. B. lib in import * as lib from “x.js” (ein weiteres ImmutablePrototypeExoticObject, das auch ansonsten komplett immutable ist)

Hinzu kommen plattformspezifische Exotic Objects, die je nach „Geschmacksrichtung“ nur in Browsern oder nur in Node.js zu finden sind.

Arrays sind relativ typische Exotic Objects. Der Großteil ihrer APIs und Verhaltensweisen ist normal, nur sehr wenige Operationen (wie das Setzen von Properties, die Array-Indizes sind oder “length” heißen) haben ein Verhalten, das sich nicht mit herkömmlichen JavaScript-Sprachmitteln abbilden lässt – abgesehen von dem einen besonderen API, mit dem in JavaScript definierte Exotic Objects möglich werden.

Auf dem Weg zu nutzerdefinierten Exotic Objects

Die bis hierhin besprochenen Features von Exotic Objects beschränkten sich auf Objekte, die entweder vom ECMAScript-Standard oder der Plattform bereitgestellt werden. Doch schon seit ECMAScript 2015 gibt es ein API, mit der wir Entwickler:innen unsere eigenen Exoten erschaffen können. Proxys sind nicht viel mehr als in JavaScript definierte Exotic Objects. Sie haben die exakt gleichen Fähigkeiten und Limitierungen wie die eingebauten Exotic Objects. Deshalb war es gar nicht schlecht, dass wir uns eine solide theoretische Basis geschaffen haben. Mit diesem Rüstzeug können wir uns im nächsten Teil dieser Serie darauf konzentrieren, was wir wirklich wollen: die Proxy und Reflect APIs verwenden, um unsere ganz eigenen Exotic Objects zu erschaffen – oder zumindest in einem ersten Schritt einen besseren Array-Klon herbeizuzaubern.

🔍 Frequently Asked Questions (FAQ)

1. Was sind Exotic Objects in JavaScript?

Exotic Objects sind spezielle JavaScript-Objekte, die sich intern anders verhalten als normale Objekte. Sie folgen nicht vollständig den Standard-Operationen wie [[Get]] oder [[Set]], sondern haben eigene interne Regeln. Ein bekanntes Beispiel sind Arrays, die ihre Länge automatisch anpassen.

2. Was macht ein Objekt in ECMAScript „exotisch“?

Ein Objekt gilt als „exotisch“, wenn es eine oder mehrere interne Standardmethoden (z. B. [[DefineOwnProperty]] oder [[Set]]) überschreibt. Dadurch verhält es sich in bestimmten Situationen anders als ein gewöhnliches „Ordinary Object“, auch wenn es äußerlich ähnlich aussieht.

3. Was ist der Unterschied zwischen Ordinary Objects und Exotic Objects?

Ordinary Objects nutzen die Standard-Implementierungen der ECMAScript-Spezifikation für alle internen Operationen. Exotic Objects weichen in mindestens einer dieser internen Methoden ab, z. B. bei Arrays, Typed Arrays oder Module Namespace Objects.

4. Was sind Beispiele für Exotic Objects in JavaScript?

Typische Exotic Objects sind Arrays, String-Objekte, Typed Arrays sowie Module Namespace Objects. Auch bestimmte interne Strukturen wie Object.prototype (in speziellen Fällen) oder ArrayBuffer-basierte Objekte verhalten sich „exotisch“.

5. Was kann man mit Proxy und Reflect in ECMAScript machen?

Mit Proxy und Reflect kann man eigene Exotic Objects erstellen oder das Verhalten bestehender Objekte gezielt steuern. Entwickler:innen können damit z. B. Zugriffe auf Properties abfangen, validieren oder verändern und so Objektlogik flexibel erweitern.

6. Wer nutzt Exotic Objects oder Proxy-APIs in der Praxis?

Diese Konzepte werden vor allem von fortgeschrittenen JavaScript-Entwickler:innen genutzt, etwa beim Framework-Design, bei State-Management-Systemen, bei Change-Tracking oder beim Bau von Libraries, die tief in das Objektverhalten eingreifen müssen.

7. Was bringt es, die ECMAScript-Spezifikation zu verstehen?

Das Verständnis der ECMAScript-Spezifikation hilft dabei, JavaScript-Interna besser zu durchdringen und komplexe Probleme zu lösen. Besonders bei Proxy, Reflect und Exotic Objects ist es wichtig, die internen Mechanismen zu kennen, um korrektes und vorhersehbares Verhalten zu gewährleisten.